古典策略告訴我們贏的方法就是「標準化」和「規模化」，隨後會導出一個方向就是「自動化」；可以這麼說，「自動化」是標準化與規模化的必然結果，標準化和規模化是「自動化」的基石。然而在這個科技演進與數據驅動的現代，安總並不採取這個策略。我們今天就秉持著「大規模定製」的精神，來建構「安全測試自動化」的基礎。

測試自動化金字塔 (Test Automation Pyramid)

這個測試自動化金字塔告訴我們一件事，就是越往下的投資報酬率越高，相對地，越往上的維護代價越大。也就是說，若是注重基礎功，則團隊應該機更多的心力放在「單元測試」和「組件測試」的自動化工作。安全性測試的重點也應放在底層，您將會有更多斬獲。

安全測試自動化要立即見效，我們選擇投資報酬率高的地方進行測試自動化。基於圖形介面的自動化測試，由於圖形介面變動頻繁、變因過多，故測試程式需經常修改，我們盡量不要去開發基於圖形介面的安全自動化測試。投入資源在產品的不穩定區域，快速的產品程式變更暗示這部分的業務需求比較活躍，是產品的重要價值所在；活躍的缺陷說明這部分程式比較複雜，可能存在業務或技術上的難題。針對這些區域建立自動化測試，能夠快速地發現新引入的缺陷，讓整個專案體會到自動化測試的價值。

安全測試模組化與客製化

很多人對駭客的想像還停留在單兵作戰的概念，其實我們是一支軍隊啊，如果您是將軍，請問您會怎麼指揮您的天才菁英們？

就像我們在駭客攻防戰 CTF 之三人小隊 (火影梗?)，我們會分配鳴人執行所有自動化測試案例，並調查失敗的測試案例；分配佐助做功能漫遊，檢查所有被修改的和受影響的功能，在此過程中執行一些快速測試，以探測典型錯誤；分配小櫻利用測試小組累積的使用者資料做系統測試，以檢查產品能否妥善地完成使用者任務。

模組化就能客製化，安總有個名言：

Encapsute What Varies. Abstract What Commons.
當我們把會變異的東西包出去後，剩下的東西就一樣了。

當我們有了模化組的設計之後，接下來思考一件事：「除錯 (Debug)」。對於安全測試者而言，除錯意味著「故障調查、漏洞偵測」。下面提供幾個提高測試模組可除錯性的方法，當然對於安全測試者就是提高「故障查出率」的方法：

1. 測試模組應盡可能地簡單：
   大多數的安全測試不需要極致的性能，測試人員應該用平實的演算法和基礎的程式庫來建構測試模組。否則，當測到問題而崩潰時，我們怎麼知道是待測物造成的，還是我的測試模組不穩定造成的？
2. 測試模組應容易閱讀：
   理解測試邏輯是發掘失敗原因的基本前提。讀者只需要閱讀測試函數就可以理解測試步驟和檢查邏輯。
3. 測試模組應需要合理的抽象和封裝：
   當我們把會變異的東西包出去後，剩下的東西就一樣了。剩下來的共通部分，可以恰到好處地讓讀者聚焦當前的測試邏輯。
4. 測試模組應檢查每一步操作的結果，發現問題立即報告：
   對待測物的任何操作都可能失敗，所以它會檢查所有操作的結果，並透過中斷、異常、日誌等方式將錯誤報告出來。第一時間報告錯誤有助於駭客們理解錯誤的根源，降低了追蹤漏洞源頭的開銷。
5. 測試模組應擁抱日誌：
   駭客們需要用日誌記錄對待測物的輸入資料、測試的執行步驟、產品的輸出結果，以全面描繪測試執行的情況。
6. 測試模組除了日誌，還可以記錄其他形式的日誌：
   測試資料庫、螢幕截圖、崩潰時的記憶體傾印。

安全測試互動化

手動測試是步行，自動化測試是駕車，人機協同測試是他人代駕。自動化測試模組完成繁重的工作，帶著駭客們快速地漫遊產品。在測試過程中，駭客們監控待測物的表現，如果發現問題，他可以「下車」調查。

這有點回答了「人工智慧時代，人類的工作將何去何從」的問題，答案就是學習新技能。難道現代人在都市叢林中，已經喪失學習人機互動新技能的能力嗎？

您可以從下列選擇合適的互動技術來應用：

1. Watri：
   用 Ruby 語言編寫的測試 Web 應用的程式庫，http://watir.com/。
2. Watij：
   用 Java 語言編寫的測試 Web 應用的程式庫，https://www.ibm.com/developerworks/cn/java/j-lo-watij/index.html。
3. JUnit：
   著名的 Java 語言單元測試框架，http://junit.org。
4. AutoHotKey：
   自動化重複的輸入。
5. DOS 腳本：
   自動化測試環境配置。
6. PowerShell 和 Excel：
   自動化分析待測物性能。
7. IronPython：
   自動化分析待測物負載 (開心，IronPython 是 Python 語言在 .NET 平台上的實作)。
   • 提取資料
   • 處理資料
   • 視覺化資料

安全測試規模化

隨著硬體性能的提高和集群計算技術的發展，大規模自動化測試 (High Volume Automated Testing, HiVAT) 已成為一種威力巨大的安全測試策略。讓安總透過「看透本質」的眼睛，帶著各位讀者一窺殿堂的奧秘。

現代人工智慧的本質是，過程不像人類，但是結果像人類；所以人工智慧不會有人類的思考過程、情緒過程、道德過程，但可能會有人類的思考結果、情緒結果、道德結果。因為非常人的運算過程非常複雜，所以等到了近代硬體計算能力上升後，這些人工智慧的思考結果終於大放異彩。不論開發或測試、攻擊或防禦均有受惠。這邊有一句話形容這個現象：

Deep Learning 現在處於「神農嘗百草」的階段。

大規模的測試案例密集地覆蓋了測試空間，能夠發現精心設計的「標準化」案例所錯過的缺陷。所以，並不是策略取代，而是策略並存：「標準化與規模化」與「客製化與碎片化」並存，後者存在的可能性基於科技與數據，簡稱「數據科學」。

我舉一些例子，您馬上就能意會：

1. 地圖砲測試法：
   以所有的郵遞區號，兩兩組合作為測試輸入，大約 10 億條導航案例。
2. 一百萬 URL 覆蓋法：
   從 alexa.com 獲得最流行的一百萬個 URL 進行健壯性檢測。
3. 檔案模糊器法：
   對原始檔案進行隨機修改，產生大量的模糊檔案，這對於提高軟體的安全性有極高價值，Microsoft Office 2013 透過模糊測試發現並修改了 2100 多個缺陷 [Gallagher12]。
4. 不知疲倦的猴子測試法：
   它隨機地從動作列表中選擇一個動作來操作待測物，並監視待測物的狀態和行為，記錄所發現的問題。猴子會連續執行整晚或幾天，如果待測物崩潰或停滯，它會重啟產品比繼續測試。

上述舉例，應能夠對擁有若干計算資源的駭客們一些啟發。但上面談的是如何發散，那怎麼收斂呢？底下安總再加碼給各位揭示「人工智能的收斂之方」：

1. 針對測試輸入資料的收斂：
   • 盡可能蒐集真實的業務資料
   • 測試資料產生器，盡可能在高權重的區域多採樣，在低權重的區域少採樣
   • 為每一條測試資料產生唯一的編號
2. 針對測試輸出結果的收斂：
   • 建構測試先知，以自動地發現待測物缺陷
   • 用狀態機模型來驅動待測物的狀態變遷
3. 針對監控過程的收斂：
   • 用獨立的監控程序監視測試程式和待測物
   • 測試程式記錄測試進度，以便重新開機後繼續執行尚未執行的測試案例
   • 測試程式主動向測試控制服務器申請測試案例，用拉模式 (Pull) 來分配測試案例
4. 針對測試失敗調查的收斂：
   • 測試程式應記錄所有它執行的測試案例和指令，以便重現漏洞
   • 一旦測試程式發現軟體漏洞，它應該盡可能地多保存被測物資訊與環境資訊
   • 用多台電腦執行測試時，測試程式應將測試結果提交到一個中心節點
   • 將測試結果儲存在關聯式資料庫，方便駭客們以 SQL 查詢、分析、分類、過濾某個陋洞的蛛絲馬跡，從而快速發現系統的漏洞本源。

不知疲倦的智慧機器，恰巧與 CTF 的「零時差攻擊」規則呼應：參賽隊伍不論何時，只要找到任何一個零時差漏洞，因為其他隊伍都還無法防禦，找到零時差漏洞的隊伍就可以隨時對其他參賽者發動攻擊得分。只要參賽者遲遲沒有修補這個漏洞，找到零時差漏洞的隊伍就可以一直得分。

《CTF 現場攻防得分規則》
資料來源：臺灣 HITCON，https://www.ithome.com.tw/news/102969